এজেন্ট এখন শুধু প্রশ্নের উত্তর দেয় না, ব্যবসার সিস্টেমে কাজও করে ফেলে। চার স্তরের ঝুঁকির সিঁড়ি, পাঁচটি নিরাপদ শুরুর ক্ষেত্র, ভেন্ডর চেকলিস্ট আর ৯০ দিনের পাইলট দিয়ে ঠিক করুন কী ছাড়বেন।
Author
Anichur Rahaman
ধরুন, দশটি outlet-এর এক retailer-এর purchasing lead সোমবার সকাল সাড়ে আটটায় অফিসে ঢুকলেন। weekend-এ vendor-এর default settings-এ চলা একটি AI agent এমন একটি stock report পড়েছে, যেখানে এক table-এ box ধরা হয়েছে 1 piece, আরেক table-এ 12 piece। ফলে সে 14টি purchase order তৈরি করেছে, প্রতিটিতে দরকারের 12 গুণ পরিমাণ, আর প্রথমটা ভোর 6:15-তে supplier-কে email-ও হয়ে গেছে। (এটি একটি কাল্পনিক উদাহরণ, কোনো বাস্তব গ্রাহকের ঘটনা নয়।)
একই agent-কে অন্যভাবে সাজালে সে ওই 14টি order খসড়া হিসেবে একটা queue-তে রেখে দিত। বাইরে কিছুই যেত না, ক্রেতা এক মিনিটেই পরিমাণ দেখে ধরে ফেলতেন, সোমবার চলত নিজের মতো। ফারাকটা AI-এর বুদ্ধিতে নয়; ফারাকটা হলো মাঝখানে কোনো মানুষ ছাড়া agent কতটা করতে পারে, তাতে।
দুই বছর আগে "ERP-তে AI" বলতে বোঝাত একটা chat box, যেটা আপনার data নিয়ে প্রশ্নের উত্তর দেয়। ২০২৬-এ software কোম্পানিগুলো বিক্রি করছে agent: এমন AI, যে শুধু কথা বলে না, তথ্য খোঁজে, সিদ্ধান্ত নেয় এবং আপনার ব্যবসার system-এর ভেতরে কাজ করে ফেলে। সে purchase order তৈরি করতে পারে, payment reminder পাঠাতে পারে, দামও বদলে দিতে পারে।
কাজের কথা, কিন্তু ঠিক এখান থেকেই ভুলের চরিত্র বদলে যায়। ভুল উত্তর দিলে chatbot-এর জন্য আপনার এক মিনিট নষ্ট হয়। আর agent যদি supplier-কে ভুল order পাঠিয়ে দেয়, নষ্ট হয় এক প্যালেট মাল।
এই লেখায় একটা ব্যবহারিক কাঠামো দিচ্ছি, যাতে আপনি ঠিক করতে পারেন — আজ আপনার ERP-তে AI agent কোন কাজটা নিজে করতে পারবে, কোনটা শুধু খসড়া করবে, আর কোনটায় এখনই হাত দেবে না। শেষে আছে vendor যাচাইয়ের একটা চেকলিস্ট এবং ৩০-৬০-৯০ দিনের একটা পাইলট পরিকল্পনা, যেটা আপনি আগামী সপ্তাহেই শুরু করতে পারেন।
এটি "অপারেশনে AI" নিয়ে তিন পর্বের সিরিজের প্রথম পর্ব। দ্বিতীয় পর্বে আছে MCP কীভাবে AI-কে ব্যবসার dataর সঙ্গে নিরাপদে জোড়ে: MCP explained। তৃতীয় পর্বে অনুমোদন, audit ট্রেইল আর human-in-the-loop নকশা: AI guardrails।
copilot তখনই উত্তর দেয় যখন আপনি জিজ্ঞেস করেন। সে data পড়ে, কথায় জবাব দেয়। জবাব ভুল হলে আপনি আগেই ধরে ফেলেন, কারণ কিছু ঘটার আগে একজন মানুষ সেটা পড়ে।
agent-কে দেওয়া হয় একটা লক্ষ্য, কিছু tool আর সেগুলো চালানোর অনুমতি। কোন tool কখন চালাবে সে নিজেই ঠিক করে, চালায়, ফলাফল দেখে এবং লক্ষ্য পূরণ না হওয়া পর্যন্ত এগোতে থাকে। আসল বিষয় এই tool-গুলোই: "draft order তৈরি করো", "stock update করো", "email পাঠাও", "refund দাও"।
ফলে ঝুঁকির জায়গাটাই সরে যায়। copilot-এর ঝুঁকি ভুল উত্তর। agent-এর ঝুঁকি ভুল কাজ — যা দ্রুত, বড় পরিসরে এবং অনেক সময় কেউ প্রতিটি ধাপ না দেখেই বারবার ঘটতে পারে।
আগাম পূর্বাভাসেও এর ছাপ স্পষ্ট। ২০২৫ সালের জুনে Gartner পূর্বাভাস দিয়েছিল, ২০২৭ সালের শেষ নাগাদ agentic AI প্রকল্পের ৪০ শতাংশের বেশি cancel হবে — কারণ খরচ বাড়ছে, ব্যবসায়িক মূল্য অস্পষ্ট আর risk control অপর্যাপ্ত (Gartner-এর press release)। একই release-এ "agent washing" নিয়েও সতর্কতা আছে: সাধারণ chatbot আর automation-কে নতুন লেবেল লাগিয়ে "agent" বলে চালানো। Gartner-এর হিসাবে, agentic feature-এর দাবিদার হাজার হাজার vendor-এর মধ্যে খাঁটি ছিল মাত্র ১৩০টির মতো।
নিরাপদ থাকার সবচেয়ে সহজ উপায় হলো "AI কি এটা পারে?" প্রশ্নটা বাদ দিয়ে জিজ্ঞেস করা, "এটা ভুল করলে কী হবে?" এই প্রশ্নে agent-এর কাজগুলো চার ধাপের এক সিঁড়িতে সাজানো যায় — নিরীহ থেকে শুরু করে ফেরানো কঠিন পর্যন্ত।
| স্তর | agent কী করে | ERP-তে উদাহরণ | ২০২৬-এ কোথায় মানায় |
|---|---|---|---|
| ১. Answer | data পড়ে, ব্যাখ্যা করে, সারসংক্ষেপ দেয় | "আগামী 10 দিনে কোন SKU শেষ হয়ে যাবে?" | read-only অনুমতিতে নির্দ্বিধায় চালানো যায় |
| ২. খসড়া | এমন নথি বানায় যেটা মানুষ যাচাই করে | purchase orderের খসড়া, পণ্যের বিবরণ, reminder email | নিরাপদ, যদি মানুষ অনুমোদন না দেওয়া পর্যন্ত কিছু পাঠানো বা পোস্ট না হয় |
| ৩. ফেরানো যায় এমন কাজ | এমন data বদলায় যা পরিষ্কারভাবে আগের অবস্থায় ফেরানো যায় | orderে ট্যাগ বসানো, stock রিজার্ভ করা, কাজের সময় বদলানো | সীমিত ও ভালোভাবে পরীক্ষিত ক্ষেত্রে চলবে — log ও undo সহ |
| ৪. টাকা বা অপরিবর্তনীয় | payment, refund, মুছে ফেলা, বাইরের কাউকে পাঠানো | supplierকে payment, refund, রেকর্ড ডিলিট | এখনকার জন্য প্রতিবার সিদ্ধান্ত নেবেন একজন মানুষ |
সিঁড়িটা দুটো কারণে কাজ করে। প্রথমত, স্তর ঠিক হয় কাজ দিয়ে, AI দিয়ে নয়। "email পাঠানো" ২ নম্বর স্তরে পড়ে যদি মানুষ নিজে send চাপেন, আর ৪ নম্বরে পড়ে যদি agent নিজেই আপনার customerদের কাছে পাঠিয়ে দেয়। দ্বিতীয়ত, নিচের ধাপে নিজের যোগ্যতা প্রমাণ করার পরই — সংখ্যা দেখিয়ে — agentকে এক ধাপ ওপরে ওঠার সুযোগ দেওয়া উচিত।
ক্রমানুসারে তিনটি প্রশ্ন করলেই সিঁড়িটা কাজ ভাগ করার নিয়মে পরিণত হয়। যে উত্তরটা আগে খাটে, কাজটা সেখানেই গিয়ে পড়ে।
সেরা শুরুটা হয় ১ আর ২ নম্বর স্তরে। এতে সময় সত্যিই বাঁচে, মানুষ প্রক্রিয়ার ভেতরেই থাকে, আর ভুল হলে ক্ষতি সামান্য। ছোট ও মাঝারি ব্যবসার জন্য ভালো কাজ করে এমন পাঁচটি ক্ষেত্র:
"সব outlet মিলিয়ে এই পণ্যটা কতগুলো আছে?" "গতকালের কোন orderের টাকা এখনো আসেনি?" এমন উত্তরের জন্য screen আর এক্সেল ঘেঁটে স্টাফদের প্রতি সপ্তাহে ঘণ্টার পর ঘণ্টা চলে যায়। লাইভ data থেকে উত্তর আনা শুধু-পড়ার agent এই খোঁজাখুঁজি বন্ধ করে দেয়। ঝুঁকি কম, কারণ সে কিছুই বদলাতে পারে না।
agent বিক্রির গতি, বর্তমান stock আর supplierের লিড টাইম দেখে প্রতিটি supplierের জন্য একটা purchase orderের খসড়া বানায়। ক্রেতা পরিমাণ দেখেন, দরকারমতো বদলান, তারপর অনুমোদন দেন। হিসাব আর টাইপের কাজটা agentের; বিবেচনা আর টাকার নিয়ন্ত্রণ মানুষের হাতে।
supplierের invoice এলে agent সেটা purchase order ও পণ্য গ্রহণের রেকর্ডের সঙ্গে মেলায়, তারপর গরমিল চিহ্নিত করে: ইউনিট প্রাইস বেশি, পরিমাণ বুঝে পাওয়া যায়নি, একই invoice দুবার এসেছে। agent পরামর্শ দেয়, সিদ্ধান্ত নেন অ্যাকাউন্ট্যান্ট। এটাই পরিচিত থ্রি-ওয়ে ম্যাচ — ক্লান্তিকর কাজ, যন্ত্রের জন্য একদম মানানসই।
agent বকেয়া invoice-এর তালিকা করে এবং customerের ভাষায় একটা ভদ্র reminderের খসড়া লেখে — কত দিন দেরি হয়েছে আর customerকে আপনি কত দিন ধরে চেনেন, সেই হিসাবে সুর ঠিক করে। কেউ পড়ে দেখে পাঠান। কয়েক সপ্তাহ ধরে খসড়াগুলো অপরিবর্তিত গৃহীত হতে থাকলে প্রথম নরম reminderটা agentকে নিজে পাঠাতে দিতে পারেন।
শত শত পণ্যের টাইটেল, বিবরণ আর মেটা টেক্সট হাতে লেখা ধীর কাজ। agent পণ্যের অ্যাট্রিবিউট থেকে খসড়া করে, সম্পাদক চোখ বুলিয়ে পাবলিশ করেন। যেসব লেখার আইনি ওজন আছে — উপাদানের তালিকা, সাইজের দাবি, ওয়ারেন্টির শর্ত — সেখানে মানুষ রাখুন।
কিছু কাজ বারবার করতে হয় বলে লোভনীয় লাগে। এগুলো এখন মানুষের হাতেই রাখুন, নয়তো agentকে শুধু খসড়ার ভূমিকায় রাখুন:
কারণটা নথিভুক্ত আছে। OWASP প্রকল্প LLM অ্যাপ্লিকেশনের Top 10-এ excessive agency-কে — অর্থাৎ কাজের তুলনায় বেশি ফাংশন, অনুমতি বা স্বায়ত্তশাসন পাওয়া AI systemকে — আলাদা ঝুঁকি হিসেবে তালিকাভুক্ত করেছে, আর ২০২৫-এর ডিসেম্বরে প্রকাশ করেছে আলাদা একটি Top 10 for Agentic Applications, যেখানে আছে goal hijacking, toolের অপব্যবহার আর বেপরোয়া agentের কথা। customerের লেখা, supplierের email কিংবা আপলোড করা PDF-এর ভেতরে agentকে উদ্দেশ্য করে নির্দেশ লুকানো থাকতে পারে। agent টাকা নাড়াতে পারলে সেই নির্দেশ বিপজ্জনক হয়ে ওঠে।
agent ততটাই নির্ভরযোগ্য, যতটা নির্ভুল data সে পড়ে আর যতটুকু অধিকার সে পায়। চালু করার আগেই দুটো ঠিক করা সহজ।
stockের হিসাব ভুল থাকলে purchase orderের খসড়াও ভুল হবে — আত্মবিশ্বাসী ভঙ্গিতে, ভদ্র ভাষায়। পাইলটের আগে মৌলিক বিষয়গুলো দেখে নিন:
agentকে দিন তার নিজস্ব account — কখনোই শেয়ার করা admin logইন নয়। অনুমতি দিন ন্যূনতম: যে module লাগে শুধু সেটার পড়ার অধিকার, যেখানে খসড়া করবে শুধু সেখানে draft তৈরির অধিকার, আর কিছু নয়। ERP যদি agentকে তার ব্যবহারকারী থেকে আলাদাভাবে সীমিত করতে না পারে, সেটাকে গুরুতর ঘাটতি ধরুন। আদর্শ হলো, agent কাজ করবে যিনি জিজ্ঞেস করছেন তাঁর অনুমতি নিয়েই — যাতে সে ওই মানুষটির চেয়ে বেশি কিছু দেখতে বা করতে না পারে।
এই সিরিজের তৃতীয় পর্বে অনুমোদন আর audit ট্রেইল নিয়ে আরও গভীরে যাব। আপাতত নিয়মটা মনে রাখুন: কোনো মানুষের যে কাজের অনুমতি নেই, তাঁর agentেরও নেই।
agent washing-এর যুগে চোখ ধাঁধানো ডেমো প্রায় কিছুই প্রমাণ করে না। নিচের প্রশ্নগুলো করুন, আর স্লাইড নয়, নির্দিষ্ট উত্তর চান।
আপনার customerরা যদি সরাসরি AI-এর সঙ্গে কথা বলেন, তাহলে যেখানে বিক্রি করছেন সেখানকার নিয়ম দেখে নিন। ইউরোপীয় ইউনিয়নে AI Act-এর স্বচ্ছতা-সংক্রান্ত বাধ্যবাধকতা কার্যকর হচ্ছে ২০২৬ সালের ২ আগস্ট থেকে; তাতে মানুষকে জানাতে হবে যে তিনি মানুষের সঙ্গে নয়, একটি AI systemের সঙ্গে কথা বলছেন।
প্রথম দুই স্তর বাস্তবে কেমন দেখায়, তা দেখতে ERP-র ভেতরে বসানো একটি AI অ্যাসিস্ট্যান্টের এই ছোট ট্যুরটি দেখুন — লাইভ ব্যবসায়িক data থেকে সে উত্তর দিচ্ছে আর খসড়া বানাচ্ছে।
পুরো কোম্পানিতে একসঙ্গে agent চালু করবেন না। ছোট, মাপা একটা চক্র চালান, আর প্রতিটি ধাপের সিদ্ধান্ত নিতে দিন সংখ্যাকে।
একটি টিম আর একটি প্রক্রিয়া বেছে নিন — ধরুন purchasing। ওপরের data-সমস্যাগুলো মিটিয়ে নিন। চালু করুন শুধু ১ নম্বর স্তর: প্রশ্ন আর সারসংক্ষেপ। মাপুন কত সময় বাঁচল, এবং তার চেয়েও জরুরি — কতবার উত্তর ভুল হলো। স্টাফরা প্রতিটি উত্তরে ঠিক বা ভুল চিহ্ন দিন।
একটি ব্যবহারক্ষেত্রে ২ নম্বর স্তর যোগ করুন, যেমন purchase orderের খসড়া। প্রতিটি খসড়া একজন মানুষের হাত ঘুরে যাবে। তিনটি সংখ্যা রাখুন: অপরিবর্তিত গৃহীত খসড়ার হার, সম্পাদিত খসড়ার হার, আর বাতিল খসড়ার হার। কেন বাতিল হলো তা লিখে রাখুন — সেই কারণগুলোই আপনার নিয়ম হয়ে উঠবে।
গ্রহণের হার বেশি আর ভুল বিরল হলে একটি সংকীর্ণ ক্ষেত্রে একটি ৩ নম্বর স্তরের কাজ অনুমোদন দিন — যেমন নির্দিষ্ট মূল্যের নিচের orderে stock নিজে থেকে রিজার্ভ করা। audit log খোলা রাখুন, undo পরীক্ষা করুন, অস্বাভাবিক কিছু ঘটলে অ্যালার্মের ব্যবস্থা রাখুন। ৯০ দিনের মাথায় সৎভাবে মূল্যায়ন করুন। সংখ্যা ভালো না হলে যেখানে আছেন সেখানেই থাকুন। সেটাও একটা ফলাফল, ব্যর্থতা নয়।
একটা সরল স্কোরকার্ড পর্যালোচনাকে সৎ রাখে:
সেই সোমবারে ফিরে আসি। সিঁড়ি মেনে চললে weekendের রান ১৪টি order supplierের কাছে পাঠায় না, ক্রেতার সারিতে রেখে দেয় ১৪টি খসড়া। ক্রেতা দেখেন প্রতিটি পরিমাণই বিক্রির ইতিহাসের বারো গুণ, কয়েক মিনিটে পুরো batch বাতিল করেন আর আইটেম মাস্টারে মাপের একক ঠিক করে দেন। বাতিলের কারণটা নিয়মের তালিকায় ওঠে, আর পরের weekendের রান বেরোয় নির্ভুল।
agent আরও ভালো হবে, আর সিঁড়িটাও সরবে: আজ যে কাজে মানুষ লাগে, log, undo আর অনুমোদনের ধাপ আস্থা অর্জন করলে দুই বছর পর সেটা রুটিন হয়ে যাবে। সবচেয়ে লাভবান হবে সেই ব্যবসাগুলো, যাদের data পরিষ্কার, অনুমতি সংকীর্ণ আর মেপে দেখার অভ্যাস আছে। এই একই ভিত্তি ঠিক করে দেয় agent আপনার dataয় কতটা নিরাপদে পৌঁছাতে পারবে — দ্বিতীয় পর্বের বিষয় সেটাই: Model Context Protocol।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
