Microsoft-এর ১০০+ agent-এ cycle time ৭৫% কম—আগে workflow বদলেছে
Microsoft ১৭ সেপ্টেম্বর ২০২৬ জানিয়েছে, নিজস্ব cloud supply-chain-এর নির্বাচিত workflow-এ ১১১টির বেশি purpose-built AI agent মোতায়েনের পর গড় cycle time প্রায় ১০ কর্মদিবস থেকে ২.৫ কর্মদিবসের নিচে নেমেছে। এপ্রিল থেকে আগস্টের পাঁচটি মাসিক planning cycle নিয়ে করা Microsoft-এর অভ্যন্তরীণ বিশ্লেষণে হ্রাসটি সর্বোচ্চ ৭৫%; agent আনার আগে দলটি end-to-end workflow সরল করে এবং shared data-র একটি single source of truth তৈরি করেছিল।
সেদিন প্রকাশিত এই ফল planning, sourcing, fulfillment ও logistics-এ Microsoft-এর নিজস্ব deployment-এর—স্বাধীনভাবে যাচাই করা industry benchmark নয়। VentureBeat-এর পর্যালোচনায় একই ১১১-agent deployment, ১৫০ জনের বেশি সদস্যের cross-functional উদ্যোগ এবং নির্দিষ্ট measurement period উঠে এসেছে; সংখ্যাগুলোর উৎস Microsoft-এর নিজস্ব বিশ্লেষণই।
৭৫% ফলটি ঠিক কোন কাজের
শিরোনামের ১০০টির বেশি agent পুরো supply chain-এর প্রতিটি কাজ স্বয়ংক্রিয় করেছে—Microsoft এমন দাবি করেনি। এগুলো নির্বাচিত cloud supply-chain workflow-এ demand-এর পরিবর্তন অনুসন্ধান, capacity model করা এবং আকাশ, স্থল ও সমুদ্রপথের পরিবহন বিকল্পকে খরচ, সময় ও carbon impact অনুযায়ী তুলনা করার মতো নির্দিষ্ট কাজ করে।
কিছু agent কেবল তথ্য দেওয়ার স্তরও পেরিয়েছে। নির্ধারিত permission ও approval threshold-এর মধ্যে তারা planner-কে purchase order update বা cancel করতে সহায়তা করতে পারে। তবে প্রকাশিত বর্ণনা agent-কে চূড়ান্ত সিদ্ধান্তের মালিক বলেনি; মানুষের review, approval ও intervention কোথায় থাকবে, সেটিও workflow design-এর অংশ।
Cycle-time ফলটিও delivery speed, inventory performance বা আর্থিক return-এর সমার্থক নয়। এটি নির্বাচিত planning workflow শেষ করতে লাগা সময়ের মাপ; Microsoft service level, error rate বা মোট cost একই সঙ্গে কতটা বদলেছে, সে তথ্য প্রকাশ করেনি।
Agent-এর আগে process ও data কেন বদলেছে
Deployment sequence-টির প্রথম ধাপ ছিল কাজের প্রবাহকে শুরু থেকে শেষ পর্যন্ত দেখা এবং সরল করা। Microsoft-এর ব্যাখ্যা হলো, ভাঙা process-এর একটি ধাপ দ্রুত করলে পরের ধাপে আরও বড় queue তৈরি হতে পারে। তাই supply-chain specialist ও engineer-রা আগে workflow map করেন, তারপর agent ব্যবহারের উপযোগী করে পুনর্গঠন করেন।
দ্বিতীয় ভিত্তি ছিল single source of truth। Planning, sourcing, fulfillment ও logistics-এর agent যদি একই demand, capacity বা order সম্পর্কে আলাদা record থেকে reasoning করে, agent-এর সংখ্যা বাড়লেও সিদ্ধান্তের সামঞ্জস্য নিশ্চিত হয় না। Shared data foundation তৈরির পরই নির্দিষ্ট দায়িত্বের agent ছড়ানো হয়েছিল—অর্থাৎ agent count ছিল redesign-এর পরের ধাপ, সূচনা নয়।
এই ক্রমটি গুরুত্বপূর্ণ হলেও ৭৫% হ্রাসকে শুধু process simplification, শুধু shared data বা শুধু agent-এর ফল হিসেবে আলাদা করা যায় না। Microsoft কোনো controlled comparison প্রকাশ করেনি; ফলটি পুনর্গঠিত workflow, অভিন্ন data, বহু agent এবং মানুষের নিয়ন্ত্রণসহ সম্মিলিত operating configuration-এর সঙ্গে যুক্ত।
Permission ও approval threshold কোথায় বসেছে
একটি demand পরিবর্তনের ব্যাখ্যা তৈরি, transport option তুলনা এবং purchase order বাতিল করা সমান ঝুঁকির action নয়। সেই কারণে agent কী পড়তে পারবে, কোন কাজ করতে পারবে, কোন action পর্যবেক্ষিত হবে এবং কোথায় মানুষের অনুমোদন বাধ্যতামূলক—এই সীমাগুলো deployment-এর মধ্যেই নির্ধারণ করা হয়েছে।
Approval threshold এখানে শুধু security control নয়; এটি operational accountability-ও ভাগ করে। কম ঝুঁকির analysis দ্রুত চলতে পারে, কিন্তু বেশি প্রভাবের transaction মানুষের নির্ধারিত সীমায় থামে। ফলে autonomy বাড়ানোর মাপকাঠি agent-এর প্রযুক্তিগত ক্ষমতা নয়, সম্ভাব্য ভুলের ব্যবসায়িক প্রভাবও।
Caseটি যে ছয় ধাপের implementation sequence দেখায়
Microsoft-এর ফল অন্য প্রতিষ্ঠানে হুবহু স্থানান্তরযোগ্য নয়। তবে deployment narrative থেকে ছয়টি পরস্পরনির্ভর স্তর স্পষ্ট হয়:
- Outcome: agent adoption নয়, cycle time-এর মতো business metric ও কোন workflow মাপা হবে তা আগে নির্ধারণ করা।
- Process simplification: end-to-end flow map করে অপ্রয়োজনীয় handoff, queue ও approval চিহ্নিত করা।
- Shared data: agentগুলোর জন্য একই সংজ্ঞা ও record-ভিত্তিক single source of truth তৈরি করা।
- Purpose-built deployment: একটি agent-কে সব কাজ না দিয়ে planning, sourcing, fulfillment ও logistics-এর নির্দিষ্ট দায়িত্ব ভাগ করা।
- Authority boundary: permission, approval threshold, monitoring এবং বাধ্যতামূলক human intervention স্পষ্ট করা।
- Measurement: একই workflow-এর আগের baseline ও নির্দিষ্ট সময়ের পরের ফল তুলনা করা, সঙ্গে মানুষের validation বজায় রাখা।
বৃহত্তর organizational context-ও technology rollout-এর চেয়ে operating model-কে বেশি গুরুত্ব দেয়। Microsoft-এর ২০২৬ Work Trend Index ১০টি বাজারের ২০,০০০ AI ব্যবহারকারীর survey-তে organizational factor-কে reported AI impact-এর ৬৭% এবং individual factor-কে ৩২%-এর সঙ্গে যুক্ত করেছে। এগুলো self-reported association, causal proof নয়; supply-chain ফলের স্বাধীন পুনরাবৃত্তিও নয়।
অন্য প্রতিষ্ঠানের জন্য সীমাটি কোথায়
বাংলাদেশ বা ভারতের কোনো enterprise একই sequence অনুসরণ করতে পারে, কিন্তু ৭৫% হ্রাসকে forecast হিসেবে নেওয়ার ভিত্তি নেই। Microsoft-এর baseline, process maturity, data quality, transaction mix, team size ও approval structure অন্য প্রতিষ্ঠানের সঙ্গে মিলবে—এমন প্রমাণ প্রকাশিত হয়নি।
Case description-এ development ও maintenance cost, model ও infrastructure expense, ভুল সিদ্ধান্তের হার, exception volume কিংবা Microsoft-এর বাইরে একই পদ্ধতির স্বাধীন ফল নেই। তাই দ্রুত cycle time আর্থিক সাশ্রয় বা উন্নত service level প্রমাণ করে না; সেগুলো আলাদা outcome ও baseline দিয়ে মাপতে হবে।
এখন পর্যন্ত নিশ্চিত সিদ্ধান্তটি সীমিত: Microsoft নির্বাচিত cloud supply-chain workflow-এ ১১১টির বেশি agent ব্যবহার করে নিজস্ব মাপে cycle time সর্বোচ্চ ৭৫% কমিয়েছে, এবং agent মোতায়েনের আগে workflow ও shared data foundation পুনর্গঠন করেছে। ফলটির ব্যাপক প্রয়োগযোগ্যতা বুঝতে দীর্ঘ সময়ের quality, cost ও exception data এবং অন্য প্রতিষ্ঠানে স্বাধীন replication এখনও প্রয়োজন।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।