Microsoft-এর ১১১ AI agent-এ cycle time ৭৫% কম—হিসাবটি internal

Microsoft ১৭ সেপ্টেম্বর ২০২৬-এ জানায়, নিজস্ব cloud supply-chain-এর নির্বাচিত workflow-এ ১১১টির বেশি AI agent মোতায়েনের পর গড় planning cycle প্রায় ১০ business day থেকে ২.৫ দিনের নিচে নেমেছে। Microsoft-এর প্রকাশিত পরিমাপে এপ্রিল থেকে আগস্ট ২০২৬ পর্যন্ত পাঁচটি মাসিক cycle ধরে cycle time ৭৫% পর্যন্ত কমার কথা বলা হয়েছে।

একই ১৭ সেপ্টেম্বর প্রকাশিত তথ্য অনুযায়ী, এটি Microsoft-এর internal analysis—স্বাধীনভাবে যাচাই করা industry benchmark নয়। ফলটি নির্দিষ্ট workflow, পুনর্গঠিত process, অভিন্ন data foundation এবং মানুষের approval ও validation-সহ একটি ব্যবস্থার; শুধু ১১১টি agent যোগ করলেই অন্য প্রতিষ্ঠানে একই হ্রাস হবে, এমন দাবি করা হয়নি।

১১১টির বেশি agent কী করেছে

Agent বসানোর আগে Microsoft-এর supply-chain বিশেষজ্ঞ ও প্রকৌশলীরা end-to-end workflow চিহ্নিত ও সরল করেন। এরপর agentগুলোর জন্য একটি অভিন্ন data source তৈরি করে planning, sourcing, fulfillment ও logistics-এর নির্দিষ্ট কাজে purpose-built agent মোতায়েন করা হয়। “১১১ agent” তাই ১১১ জন কর্মীর বিকল্প নয়; সংখ্যাটি বহু-agent ব্যবস্থার আলাদা software component বোঝায়।

Agentগুলো demand-এর পরিবর্তনের কারণ অনুসন্ধান, প্রয়োজনীয় capacity model এবং আকাশ, স্থল ও সমুদ্রপথের পরিবহন বিকল্পকে খরচ, সময় ও carbon impact অনুযায়ী তুলনা করে। নির্ধারিত permission ও approval threshold-এর মধ্যে কয়েকটি agent planner-কে purchase order বদলানো বা বাতিল করতেও সহায়তা করে। ফলে এগুলো শুধু প্রশ্নের উত্তর দেওয়া chatbot নয়, আবার মানুষের নিয়ন্ত্রণ ছাড়া চলা সম্পূর্ণ autonomous supply chain-ও নয়।

Inc.-এর ১৭ সেপ্টেম্বরের প্রতিবেদনে selected workflow-এ ১১১টি agent ও ৭৫% cycle-time reduction-এর পাশাপাশি প্রতিটি agent-এর আলাদা identity, সীমিত permission এবং traceable, auditable ও reversible action রাখার সুপারিশ তুলে ধরা হয়েছে। অর্থাৎ ফলটির সঙ্গে workflow redesign ও governance—দুটিই যুক্ত ছিল।

৭৫% বলতে ঠিক কী মাপা হয়েছে

মূল metric ছিল নির্বাচিত planning workflow সম্পন্ন করার গড় cycle time। পাঁচটি মাসিক planning cycle-এ সময় প্রায় ১০ business day থেকে ২.৫ দিনের নিচে নামে; Microsoft এই ফলকে “up to 75%” হিসেবে প্রকাশ করেছে। “প্রায়” এবং “নিচে”—দুই সীমাই থাকায় প্রকাশিত rounded সংখ্যাগুলো দিয়ে আরও নির্ভুল শতাংশ দাবি করা ঠিক হবে না।

এই measurement Microsoft-এর পুরো supply chain-এর end-to-end lead time নয়। এটি সব procurement বা logistics operation-এর গতিও মাপে না; একই সঙ্গে accuracy, deployment cost, return on investment কিংবা ভুল সিদ্ধান্তের হারও প্রকাশ করে না। তাই ৭৫% হলো নির্দিষ্ট workflow-এর সময়সংক্রান্ত case result, সামগ্রিক operational performance-এর পূর্ণ হিসাব নয়।

Demand-plan investigation-এর জন্য আলাদা একটি ফল দেওয়া হয়েছে। প্রতি মাসে ২০টির বেশি investigation-এ পরিবর্তনের কারণ খুঁজে মানুষের যাচাই করা ব্যাখ্যা তৈরি করতে আগে পাঁচ থেকে সাত দিন লাগত; পরে তা কয়েক ঘণ্টার নিচে নামে এবং কিছু investigation ২০ মিনিটেরও কম সময়ে শেষ হয়। এটি ১০ দিন থেকে ২.৫ দিনের নিচে নামা planning-cycle metric থেকে পৃথক—দুটি ফল এক করে পড়া যাবে না।

কেন সংখ্যাটি সাধারণ benchmark নয়

পরিমাপটি সেপ্টেম্বর ২০২৫ থেকে আগস্ট ২০২৬ পর্যন্ত ১৫০ জনের বেশি সদস্যের cross-functional উদ্যোগের অংশ। Agent মোতায়েনের আগে workflow map ও simplify করা হয়েছিল এবং shared data foundation তৈরি হয়েছিল। ফলে কতটা উন্নতি agent থেকে, আর কতটা process redesign, data quality, engineering বা human review থেকে এসেছে—প্রকাশিত aggregate ফল তা আলাদা করে দেখায় না।

VentureBeat-এর বিশ্লেষণ পাঁচটি cycle, ১০ business day থেকে ২.৫ দিনের নিচে নামা এবং ১৫০ জনের বেশি সদস্যের internal উদ্যোগের সীমা মিলিয়ে দেখেছে; প্রকাশনাটি স্পষ্ট করেছে যে ফল independently validated নয় এবং Microsoft নিজেও একে নির্দিষ্ট workflow ও measurement period-এর বাইরে সাধারণীকরণ করেনি। Microsoft enterprise AI software ও infrastructure বিক্রি করে—ফলে প্রকাশিত case result-এর commercial context-ও প্রাসঙ্গিক।

অন্য প্রতিষ্ঠানের ERP, data completeness, approval chain, মৌসুমি demand এবং exception-এর ধরন ভিন্ন হতে পারে। পাঁচটি ধারাবাহিক cycle পরিবর্তনটির প্রাথমিক স্থায়িত্ব দেখালেও দীর্ঘমেয়াদি performance প্রমাণ করে না। অতএব ৭৫% একটি উল্লেখযোগ্য internal result, কিন্তু vendor-neutral industry average বা ভবিষ্যৎ ফলের guarantee নয়।

Identity, permission ও rollback-এর শিক্ষা

Supply-chain agent বাস্তব record পড়তে বা বদলাতে পারলে shared service account ব্যবহার করলে কোন action কার, তা শনাক্ত করা কঠিন হয়। আলাদা workload identity প্রতিটি agent-এর data access, tool call ও action audit trail-এ চিহ্নিত করতে সাহায্য করে। Permission নির্দিষ্ট দায়িত্বের ন্যূনতম সীমায় রাখলে ভুল বা compromised agent-এর সম্ভাব্য প্রভাবও ছোট রাখা যায়।

Human oversight মানে প্রতিটি output হাতে পরীক্ষা করা নয়; ঝুঁকির মাত্রা অনুযায়ী approval threshold ঠিক করা। কম-ঝুঁকির analysis agent সম্পন্ন করতে পারে, কিন্তু বড় allocation change, purchase-order cancellation বা সহজে ফেরানো যায় না এমন financial action মানুষের অনুমোদনের আওতায় থাকা উচিত। Input, tool call, output, approval ও override-এর record একসঙ্গে থাকলে পরে সিদ্ধান্তটি পুনর্গঠন করা সম্ভব হয়।

Reversible action-এর অর্থ, agent কোনো planning parameter বা operational record বদলালে আগের অবস্থায় ফেরার পথ অথবা সমতুল্য compensating action রাখা। Rollback ভুল হওয়া বন্ধ করে না; তবে ক্ষতির পরিধি সীমিত করে এবং agent-কে কতটা autonomy দেওয়া নিরাপদ, তার বাস্তব সীমানা তৈরি করে।

বাংলাদেশ ও ভারতের enterprise দলের জন্য যাচাইয়ের ছক

Microsoft-এর শতাংশ সরাসরি target হিসেবে নেওয়ার চেয়ে একই measurement discipline অনুসরণ করা বেশি যুক্তিসংগত। বাংলাদেশ বা ভারতের কোনো enterprise দলের ক্ষেত্রে প্রথমে একটি সীমাবদ্ধ workflow, একই start ও end point এবং agent চালুর আগের baseline নির্ধারণ করতে হবে। Human review-এ ফেরত যাওয়া case, rework ও failed action বাদ পড়লে cycle time কম দেখালেও প্রকৃত operational ফল ধরা পড়বে না।

• প্রতিটি agent-এর আলাদা identity, নির্দিষ্ট দায়িত্ব ও জবাবদিহির owner রাখতে হবে;
• data, API ও action permission প্রয়োজনীয় ন্যূনতম সীমায় বাঁধতে হবে;
• cycle time-এর সঙ্গে accuracy, exception rate, human effort ও incident count মাপতে হবে;
• গুরুত্বপূর্ণ write action-এর জন্য approval gate, audit trail ও rollback রাখতে হবে;
• একাধিক planning cycle-এ একই সংজ্ঞা ও একই measurement boundary ধরে তুলনা করতে হবে।

স্থানীয় regulation, data-residency requirement এবং প্রতিষ্ঠানের approval policy অনুযায়ী অতিরিক্ত control প্রয়োজন হতে পারে। Microsoft-এর ফলটি কী সম্ভব তার একটি case দেখায়; স্থানীয় business case প্রমাণ করতে সংশ্লিষ্ট প্রতিষ্ঠানকেই নিজস্ব baseline, quality metric ও validation period তৈরি করতে হবে।

এখনও যা জানা যায়নি

প্রকাশিত তথ্যে পাঁচটি planning cycle-এর aggregate ফল আছে, কিন্তু cycle-ভিত্তিক আলাদা data, agent-পিছু contribution, error rate, implementation cost বা rollback-এর ঘটনার হিসাব নেই। কোন agent, process change বা control উন্নতির কত অংশ ঘটিয়েছে, তাই নির্ধারণ করা সম্ভব নয়।

এখন পর্যন্ত নিশ্চিত সিদ্ধান্ত সীমিত: Microsoft-এর পুনর্গঠিত cloud supply-chain workflow-এ ১১১টির বেশি agent ব্যবহারের সঙ্গে selected cycle time ৭৫% পর্যন্ত কমেছে, আর demand-plan investigation-এ human validation বজায় ছিল। একই architecture অন্য প্রতিষ্ঠানে একই ফল দেবে কি না বুঝতে দীর্ঘ সময়ের quality, cost, failure ও governance data প্রয়োজন হবে।

আরও পড়ুন:

• ProcessUnity agent-এ intake ৫৪% দ্রুত—ফলটি এখনো এক গ্রাহকের
• AIR পেল ৫ কোটি ডলার—AI agent-এর plugin এখন supply-chain ঝুঁকি
• Cursor agent নিজের server-এ চলবে—তবু reasoning থাকবে cloud-এ